fix(receiver): stop claiming the receiver is listening when it is not - #39

What happened

A colleague ran openplay-receiver on a Linux box and it never appeared in the sender's list. Nothing was wrong with their setup, their network, or their firewall — the receiver cannot be discovered by construction, and three separate messages told them otherwise.

Evidence gathered while diagnosing it:

The control matters: mDNS browsing works fine. Nothing on the LAN advertises _openplay._tcp.

And the crate explains why — its whole dependency list is:

openplay-common, egui, eframe, clap, anyhow, tracing

No openplay-discovery → cannot advertise. No openplay-signaling → cannot listen. main.rs parses args, loads config, and opens a window. That is the entire program, and it matches what CLAUDE.md already documents about the OpenPlay path being unwired.

The three false claims

1. --name help said "shown in mDNS discovery". The flag does work — it sets the window heading — but nothing advertises it.
2. --port help said "Override signaling port". Nothing binds it.
3. The window rendered Listening on port 7290.

The third is the damaging one: it is what a user actually looks at, and it states plainly that the receiver is listening. It never was.

The fix

• --name — documents that it sets the window heading and explicitly not discovery.
• --port — marked reserved, and now logs a warning when passed, so an effect-free flag announces itself at the point of use:

  WARN openplay_receiver: --port has no effect yet: this receiver does not listen for connections port=7290
  

  Kept rather than removed: it still overrides config and validates, so it keeps working unchanged once the signaling server is wired up.
• The waiting page — no longer says "waiting for a sender" or "listening on port N". It states that the receiver is a placeholder which advertises nothing and accepts no connections, and points at README documents OpenPlay/WebRTC casting and TLS cert generation that aren't wired up yet #11.

No behaviour change beyond the warning. This is the same non-functional receiver, now describing itself accurately.

Verification

fmt --check clean, clippy --all-targets --all-features -D warnings clean, cargo test --all 216 passed / 0 failed. --help output and the startup warning both checked by running the binary.

Does not make the receiver discoverable — that is #11, and it is a genuinely larger piece of work (advertiser, signaling server, SDP/ICE, ReceiverPipeline, plus the sender's Protocol::OpenPlay arm). Making it merely visible without any of that would put an unreachable entry in the sender's list, which is worse than absent.